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REMARKS/ARGUMENTS 

These remarks are submitted in response to the final Office Action dated 
September 21, 2006 (Office Action). This response is file concurrently with a Request 
for Continued Examination (RCE). The Examiner is expressly authorized to charge all 
fees due to Deposit Account No. 50-0951. 

In the Office Action, Claims 1-28 were rejected under 35 U.S.C. § 103 (a) as 
being unpatentable over U.S. Published Patent Application No. 2002/0010715 to Chinn, 
et al. (Chinn), in view of U.S. Patent No. 6,275,378 to Schuba, et al. (Schuba). 
Additionally, Claims 27 and 28 were rejected at pages 3-4 of the Office Action under 35 
U.S.C. § 101 as being directed to non-statutory subject matter. 

Applicants have amended independent Claims 1, 14, and 27 to further emphasize 
certain aspects of the invention. Applicants have cancelled Claims 2, 3, 15, and 16. The 
claim amendments, as discussed below, are fully supported throughout the Specification. 
No new matter has been introduced through the claim amendments. 

Aspects Of Applicants' Invention 

It may be useful to reiterate certain aspects of Applicants' invention prior to 
addressing the cited references. One embodiment of the invention, typified by amended 
Claim 1, is a method of providing help within an interactive voice response application 
executed by an interactive voice response system. 

The method can include determining an interactive voice response event 
corresponding to a request for help. The method can further include classifying the event 
as a default help request if the event is a no-match event or a time-out event occurs, and 
classifying the event as a user initiated help request if the event is an explicit, application- 
recognizable request for help. Specifically, a no-match event occurs when the event is 
not associated with a valid option provided to the user by the application. (See, e.g., 
Specification, p. 5., paragraph [0012], lines 3-4; see also p. 10, paragraph [0026], lines 3- 

9 

{WP350658;1} 



USApplnNo. 10/670,632 
Amendment Dated November 20, 2006 
Reply to Office Action of Sept. 21, 2006 
Docket No. IBM BOC9-2003-0061 (431) 

5.) A time-out event occurs if a user fails to respond to a system prompt within a 
predetermined duration. (See, e.g., Specification, p. 5., paragraph [0012], lines 5-6; see 
also p. 10, paragraph [0026], lines 6-8.) 

According to the method, a time for receiving user input can be set to a default 
value if the event is classified as a default help request. Conversely, if the event is 
classified as a user initiated help request, the time for receiving user input can be set to a 
value less than the default value. The interactive voice response application can execute 
a programmatic action upon expiration of the time for receiving user input. 

The Claims Define Over The Prior Art 

Claims 1, 14, and 27 

Independent Claims 1, 14, and 27 were each rejected as being unpatentable over 
Chinn in view of Schuba. Chinn is directed to a system and method of Web browsing 
using a Web-enabled "limited" display device or "voice commands." (See paragraph 
[0006]; see also Abstract.) Schuba, by contrast, is directed to enhancing security within 
the context of a data communications network. (See, e.g., Col. 1, lines 13-17, and lines 
57-60.) In particular, Schuba involves detecting and classifying messages comprising 
network-distributed Transmission Control Protocol (TCP) packets. Schuba's intent 
detecting and classifying the messages is explicitly to defend against denial-of-service 
attacks instigated over a data communications network. 

Applicants respectfully submit that neither Chinn nor Schuba, alone or in 
combination, teaches or suggests every feature of Applicants' invention. For example, 
neither of the cited references teaches or suggests distinguishing between events that are 
characterized as default help requests versus those events that are characterized as 
explicit user requests for help. Accordingly, neither Chinn nor Schuba teaches or 
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suggests providing help to users of an interactive voice response application based on this 
distinction. 

Chinn does not distinguish between default help requests and user-initiated help 
requests. Chinn's failure to make this distinction is underscored by the fact that Chinn 
treats a recognized user request and an unrecognized user request identically: 

"The help counter keeps track of the number of times help messages are 
played for a node currently being visited. A help message is usually 
provided to the user in case the system does not recognize the user's request 
or at the user's request . Thus, the help counter is incremented until the 
system successfully moves to the next node or the session ends. If the 
system browses that node again at a later time, then the counter would be 
reset, at step 1305." (p. 12, paragraph [0143].) (Emphasis supplied.) 

According to Applicants' invention if a user's request is not recognized, a no- 
match event is deemed to have occurred. Such an event corresponds to a default help 
request, according to Applicants' invention. Chinn, by contrast, does not make any such 
distinction. Accordingly, Chinn treats the recognized user request the same as a request 
that the system does not recognize. 

In another portion, cited at page 5 of the Office Action, Chinn distinguishes 
between an "explicit" system prompt and one that provides a user with a "list of choices:" 

"Once a greeting has been built by the system, then the system moves to 
step 1320 to determine whether an explicit prompt is included in the routing 
node. A prompt is typically provided to the user to elicit a response. An 
explicit prompt is played verbatim by the system. For example, an explicit 
prompt for Routing Node 1 could be "What city's weather are you 
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checking?" Alternatively, in some embodiments of the invention, a prompt 
may provide a user with a list of choices from which to choose. For 
example, the following prompt may be provided: "Choose weather for Los 
Angeles, New York, or Dallas." If an explicit prompt is not included in the 
routing node, then at step 1325, the system builds a prompt based on 
keywords included in the routing node. The prompt built by the system 
could be, for example, "What city, please?" or "Choose weather for Los 
Angeles, New York, or Dallas." In certain embodiment, the manner in 
which prompts are built are based on the attributes and properties defined in 
the style sheet." (p. 12, paragraph [0148].) 

Elsewhere, in a portion also cited at page 5 of the Office Action, Chinn describes a 
system response to a user's invoking a "help command:" 

"FIG. 13 is a flow diagram of an exemplary method 1600 for 
providing a user with assistance, according to an embodiment of the 
invention. Method 1600 may correspond to one aspect of operation 
for voice browsing system 10. A user, while using the system, can 
request for help at any point during navigation. When a user requests 
assistance by invoking the help command (e.g., by saying "help"), 
then at step 1605 the help counter N is incremented. At step 1610, 
the system retrieves the label for the node currently visited by the 
user. The node label is associated, in one or more embodiments, with 
the content of the node and is used to identify that node. The label 
can be a keyword included or associated with the node, for 
example." (p. 15, paragraph [0175].) 
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Applicants respectfully submit, however, that neither Chinn's distinction between explicit 
and non-explicit prompts, nor Chinn's provision of help commands, provides any basis 
for distinguishing between an event characterized as a default help request and an event 
characterized as a user-initiated help request. 

More particularly, Chinn does not classify an event as a default help request if 
either a no-match event or a time-out event occurs, while classifying an event as a user- 
initiated help request if the event is a request for help and not some other type of request, 
as recited in amended Claims 1,14, and 27. As explicitly recited in the claims a default 
help request occurs when either a no-match event or a time-out event occurs, according 
Applicants' invention. The no-match event occurs when an event does not correspond to 
a user option provided by the application, whereas the time-out event occurs if a user fails 
to respond to an application prompt within a predetermined duration of time. By 
contrast, a user-initiated help request is an explicit, recognized request other than a non- 
help request. Chin fails to make any of these distinctions, and accordingly, fails to treat 
the distinct events differently. Instead, as already noted, Chinn treats a no-match event 
and a recognized request event identically. (See p. 12, paragraph [0143].) 

One aspect of Applicants' invention is the recognition of the source of a common 
problem that arises with the use of interactive response applications, namely, that the 
ordinary user is helped if given more time to provide input after receiving a response to a 
default help request, and if given relatively less time to provide input after receiving a 
response to a user-initiated help request: 

"users that receive help by default generally require a delay period of 
between six and eight seconds to digest the audibly presented options and 
to input their selection. In contrast, users that have explicitly selected help, 
generally require a delay period of three seconds or less to input a desired 
help option. Additionally, users that have explicitly requested help are less 
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confused when presented with additional help options after a pause than 
users that received the initial help options by default. For the above 
reasons, it can be beneficial to automatically present a comprehensive 
second-level menu of help after pausing for a relatively short time-out 
period whenever the first-level help menu has been explicitly selected." 
(Specification, p. 5, paragraph [001 1].) 

This recognition of the source of a problem is itself an inventive aspect of Applicants' 
invention that warrants consideration. See Eibel Process Co. v. Minnesota and Ontario 
Paper Co., 261 U.S. 45 (1923). More fundamentally, however, Applicants' invention 
encompasses specific features not contemplated by the cited references. Chinn's failure to 
distinguish between default help requests and user-initiated help requests, precludes 
Chinn's classifying an event as either a default help request or a user-initiated help 
request. 

In one portion cited in the Office Action, Chinn describes setting a "timeout 
counter." (p. 12, paragraph [0144], lines 1-3.) Chinn's timeout counter, however, "keeps 
track of the number of times the system does not receive or recognize a user request." 
Although Chinn further describes that the system "allows a user to submit a request or 
provide a response to a prompt within a certain number of seconds," Chinn does not 
provide different times for responding depending on whether an event is a default help 
request - that is, a failure to recognize the user's response or a failure of the user to input 
a response - or is a user-initiated help request: 

A timeout counter keeps track of the number of times the system does not 
receive or recognize a user request while visiting the current node. In one or 
more embodiments, the system allows the user to submit a request or 
provide a response to a prompt within a certain number of seconds. If no 
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request is submitted by the user, or if the delay in providing the request is 
longer than the allotted threshold, then the system plays a timeout message 
and increments the timeout counter . The timeout counter is incremented for 
the current node until the system successfully moves to the next node or the 
session ends. If the system browses that node again at a later time, then the 
counter would be reset at step 1305. (p. 12, paragraph [0144].) 

The quoted language describes a system action that is taken if the user fails to 
provide either a system-recognizable response or no response at all. The events are, 
respectively, a no-match event and a time-out event. Chinn says nothing about treating 
both such events as a default help request that is distinguishable from an explicit, user- 
initiated help request. The fact that the timeout counter is incremented for a time-out 
event as well as a no-match event, suggests nothing about setting different times for the 
user to respond depending on whether the response is classified as a default help request 
or a user-initiated help request. Indeed, nothing in this portion of Chinn addresses 
explicit help requests submitted by a user. 

Chinn, in another portion cited in the Office Action, describes changing messages 
that are provided to a user according to the "value of the timeout counter," but nothing 
suggests setting different times for a user to respond depending on whether an event is a 
default help request - either a failure to recognize the user's response or a failure of the 
user to input a response - or is a user-initiated help request: 

"FIG. 14 is a flow diagram of an exemplary method 1700 for recognizing 
user requests. Method 1700 may correspond to one aspect of operation for 
voice browsing system 10. After the system provides the user with a 
prompt, then at step 1705 the system listens for a user response to that 
prompt. In certain embodiments, the system may also be implemented to 
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listen for a user request even before or while a prompt or a greeting is being 
played. If the system does not receive a user response or request, at step 
1710 the system determines whether a timeout condition has been met. 

"The timeout condition, in one embodiment, is dependent on the amount of 
time passed before the system recognizes that a request has been submitted 
by the user. For example, if 5 seconds have passed before a user request is 
received, then at step 1712 a timeout message is provided to the user, 
indicating the reason for the timeout. An exemplary timeout message may 
provide: "No request received." As discussed earlier, when a node is 
visited, the counters associated with that node, including the timeout 
counter, are reset. When a timeout message is played, the timeout counter is 
incremented by a certain integer value, such as 1 . 

"The system tracks the value of the timeout counter until it reaches a 
threshold value. Prior to reaching the threshold value, in some 
embodiments, the system handles a timeout condition by replaying the 
prompt for the visited node again and waiting for a user response. Based on 
the value of the timeout counter, various timeout messages and or options 
may be provided to the user. For example, in some embodiments, as the 
value of the timeout counter increases, the messages provide more helpful 
information and instructions guiding the user on how to proceed. Once the 
timeout threshold is reached, then the system plays a last resort timeout 
message and returns the user to the main menu, for example." (p. 16, 
paragraphs [0183]-[0186].) 
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Each of the events described in the quoted portion of Chinn pertains to either the 
user's failure to provide a system-recognizable response or any response at all. Again, 
both such events are classified according to Applicants invention as help default requests. 
Nothing is described in the quoted language that pertains to user-initiated help requests. 

It follows that Chinn does not teach or suggest setting a default time for receiving 
input if an event is classified as a default help request and setting less time for providing 
input if an event is classified as a user-initiated help request. Indeed, as explicitly noted 
at page 6 of the Office Action, "Chinn does not disclose setting the time to a value less 
than the default value." More fundamentally, however, Chinn by failing to classify an 
event as either a default help request or a user-initiated help request, is unable to set a 
time to a default value after the former event and set a time less than the default value 
after the latter event. 

There is no teaching, suggestion, or motivation for combining Chinn and Schuba 

Schuba is cited at page 6 of the Office Action as disclosing merely the setting of a 
time to a value less than a default value. It is further stated that 

"It would have been obvious to one of ordinary skill in the art, having the 
teachings of Chinn and Schuba before him at the time the invention was 
made, to modify setting a time as taught by Chinn to include setting a time 
to less than the default as taught by Schuba, because Chinn teaches setting a 
timeout period for [a] user response (p. 12, para. 144; p. 16, para. 183-185) 
and Schuba teaches setting a timeout period to a value less than the default 
(col. 10, lines 25-28) so that the timeout period taught by Chinn could be 
set to a value less than the default." (Office Action, p. 6.) 
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Applicants respectfully submit that this merely states that Chinn teaches one thing 
("setting a timeout period to a value less than the default") and Schuba teaches another 
("setting a timeout period to a value less than the default") so that when added together 
they yield Applicants' invention. What is not stated is any teaching, suggestion, or 
motivation that would lead one to combine the references in the first place. 

For example, neither the references themselves nor the prior art generally suggests 
anything about setting one time for a user to respond following a default help request, but 
setting another time for a user to respond following an explicit help request. Even if 
Schuba teaches "setting a timeout period to a value less than the default." that suggests 
nothing about which event - the default help request or the user-initiated help request - 
should be associated with a shorter time interval . 

Even when combined, Chinn and Schuba fail to teach every aspect of the invention 

Neither Chinn nor Schuba classify an event as either a default help request or a 
user-initiated help request. Thus it is logically impossible to infer from either that it is 
more advantageous to afford more time for a user to respond after a default help request 
and less time after an explicit help request. Neither Chinn nor Schuba teach that one time 
should be set for a default help request (i.e., a single class: either a no-match or a time-out 
event) and a shorter time set for a user-initiated help request. Applicants respectfully 
submit that, whereas nothing in the prior art suggests which event - the default help 
request or the user-initiated help request - should be associated with a shorter time 
interval, to assert that the references teach or suggest this feature amounts to an improper 
hindsight reconstruction based upon Applicants' own invention . 

Schuba merely describes reducing a timeout to prevent a denial of service attack in 
the context of data communications networking. Chinn describes user requests that are 
help requests. Chinn also describes user requests that are unrecognizable to a system; 
that is, no-match events. And Chinn describes setting a time-out that leads to an 
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automatic response if a user provides no response within a prescribed time interval; that 
is, an automatic response to a time-out event. Neither reference, however, teaches or 
suggests that both the no-match event as well as the time-out event should be classified as 
a single-class event: a default user help request. By not doing so, both references fail 
distinguish between this class of default events and an explicit user-initiated help request. 
Therefore, neither reference teaches, as Applicants' invention does, the setting of one 
time value for the default help request (regardless of whether it is a no-match or time-out 
event) and setting a lower time value for a user-initiated request. 

Accordingly, even when Chinn is combined with Schuba, the combination still 
fails to teach the features recited in independent Claims 1, 14, and 27, as amended. 
Applicants respectfully submit, therefore, that each of Claims 1,14, and 27, as well as the 
remaining claims dependent thereon, define over the prior art. 

Claims 5. 18. and 28 
For similar reasons, neither Chinn nor Schuba, alone or in combination, teaches or 
suggests every feature recited in independent Claims 5, 18, and 28. Chinn does not 
provide even a remote suggestion of treating an explicit user request for help differently 
than all other user inputs or responses. Indeed, nothing in Chinn suggests any recognition 
that explicit user requests for help are unique from other system inputs or responses 
provided by a user. As already noted, moreover, neither Schuba's reduction of a timeout 
interval in the context of data communications networking to avoid denial of service 
attacks nor the prior art generally suggest which events - an explicit user request for help 
or other user inputs or responses - should be associated with a reduced time interval. 
Accordingly, Applicants respectfully submit that the references do not teach or suggest 
every feature recited in Claims 5, 18, and 28, and that the claims as well as those 
dependent thereon define over the prior art. 
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Claims 27 and 28 

At pages 2-3 of the Office Action, Claims 27 and 28 were rejected as being 
directed to non-statutory subject matter because "the language of the claims raises a 
question as to whether the claimed systems are directed merely to an abstract idea that is 
not tied to ... a machine which would result in a practical application producing a 
concrete, useful, and tangible result." Applicants respectfully point out, however, that the 
claims recite "means for" producing the claimed results. Accordingly, the claims are 
directed to a "machine." The issue was explicitly addressed by the Federal Circuit in 
State Street Bank & Trust Co. v. Signature Financial Group, Inc., 149 F. 3d 1368 (1998), 
where the court ruled that the lower court erred by construing such claims as being drawn 
to a "process," stating that when "properly construed in accordance with § 1 12, \ 6, [such 
a claim] is directed to a machine." 149 F. 3d, at 1371. In the present case, the means for 
language must be viewed in terms of the supporting structure, the system, described in 
the written description. (See, e.g., Specification, paragraph [0020].) 

Moreover, regardless of whether the claims are constructed as being drawn to a 
machine or a process, the inventions described in the respective claims indeed yield 
concrete, useful, and tangible results. Both claims, for example, include means for 
setting a time as well as means for providing audible messages based on determined 
outcomes. Applicants respectfully submit that these results are no less concrete or 
tangible than, for example, enhancing a message record associated with a long-distance 
telephone call by adding a primary interexchange carrier indicator. See AT&T Corp. v. 
Excel Communications, Inc., 172 F. 3d 1352 (Fed. Cir. 1999). 

Applicants respectfully submit, therefore, that Claims 27 and 28 are indeed drawn 
to statutory subject matter. Applicants further respectfully submit that, for the reasons 
stated above, the claims further define over the prior art. 
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CONCLUSION 



Applicants believe that this application is now in full condition for allowance, 
which action is respectfully requested. Applicants request that the Examiner call the 
undersigned if clarification is needed on any matter within this Amendment, or if the 
Examiner believes a telephone interview would expedite the prosecution of the subject 
application to completion. 



Respectfully submitted, 



Date: November 20. 2006 




Gregory A. Nelson, Registration No. 30,577 
Richard A. Hinson, Registration No. 47,652 
AKERMAN SENTERFITT 
Post Office Box 3188 
West Palm Beach, FL 33402-3188 
Telephone: (561) 653-5000 
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